Billing system and method for micro-transactions

ABSTRACT

Billing a customer through an intermediary billing system for a transaction by receiving, at the intermediary billing system, a transaction request associated with a transaction amount and a customer identification code, validating, in the intermediary billing system, the transaction request by determining whether the customer identification code corresponds to a customer that is registered with the intermediary billing system, and sending, in the case that the transaction request is valid, a billing event trigger associated with the customer identification code to an external billing mechanism, the billing event trigger representing the transaction amount.

CROSS-REFERENCE TO RELATED APPLICATIONS

This present application claims the benefit of priority as aContinuation under 35 U.S.C. §120 of U.S. patent application Ser. No.11/446,973, filed Jun. 6, 2006 and entitled “BILLING SYSTEM AND METHODFOR MICRO-TRANSACTIONS,” which in turn claims the benefit of priorityunder 35 U.S.C. §119 from U.S. Provisional Patent Application Ser. No.60/687,663 entitled “METHOD AND SYSTEM BY WHICH MICRO TRANSACTIONS AREPROCESSED,” filed on Jun. 6, 2005, and U.S. Provisional PatentApplication Ser. No. 60/689,641 entitled “METHOD AND SYSTEM BY WHICHMICRO PAYMENT TRANSACTIONS OCCUR VIA A WIRELESS DEVICE AND/OR INTERNETPORTAL,” filed on Jun. 10, 2005, all of which are incorporated herein byreference in their entirety for all purposes.

FIELD OF THE INVENTION

The present invention concerns the automated processing of transactions,including small transactions known as micro-transactions. In particular,the invention concerns the use of an intermediate billing system thatacts on behalf of third party providers of content or services byinteracting with various external billing mechanisms to effectuatetransactions between such third party providers and their customers.

BACKGROUND OF THE INVENTION

While credit card use and automatic credit card billing is a common wayto conduct business transactions in many countries, they are notnecessarily the best way in some situations. In particular, there aremany users of the internet that do not have access to a credit card ordo not want to use their credit card for an internet based transactionout of security concerns. Many such users most likely have a mobilephone or mobile device, and it would be more easy and efficient to havea mechanism for billing the user for transactions through the user'spre-existing account with the mobile carrier associated with the user'smobile phone number. In addition, the use of a credit card iseconomically viable only if the transaction amount, or a volume of suchtransactions, exceeds a particular amount that depends on the underlyingefficiency of the billing and collecting system implemented by themerchant and by the credit card provider. Currently, mobile phonecarriers routinely bill users for small transactional amounts, such as aone minute call, or portion thereof, and are able to bill and collectfor these small transactions while making a profit. These smalltransactions are referred to as micro-transactions and, in terms of U.S.currency, can be as small as a few pennies, although larger transactionsoccur as well.

Retailers or vendors, such as internet commercial websites, may desireto provide their respective content or services to mobile phone usersvia the internet or directly through the user's mobile phone, and billthe user for such content or services as micro-transactions. Currently,a retailer or vendor will find it very difficult and inefficient to billand collect for such a micro-transaction because the retailer/vendorwould need to negotiate and enter into a contractual relationship withthe mobile phone carrier in order to bill the mobile phone usersubscribed to that carrier. The process is further complicated by thefact that the universe of customers with mobile phones use differentmobile phone carriers. Accordingly, the retailer/vendor would need toenter into contractual relationships with many different mobile phonecarriers in order to be able to provide a mobile phone basedmicro-transaction billing option to the desired global market of mobilephone users. A retailer or vendor can try to use billing mechanismsother than mobile carriers, such as prepaid card services, web-basedpayment services, bank account and credit card billing services, andother such external billing mechanisms to support customer transactions.However, in such examples, the same problem still exists for thevendor/retailer because they would still need to have pre-existingrelationships with all of the various external billing mechanisms thattheir various customers wish to use for payment of transactions.

Thus, there exists a need for a system and method that allowsretailers/vendors to easily conduct transactions, many of which may bemicro-transactions, with a global market of customers, where thetransactions are easily billable through a single intermediate billingsystem which can effectuate the transaction through a wide variety ofexternal billing mechanisms on behalf of the retailer/vendor, therebyeliminating the need for the retailer/vendor to individually establish apre-existing relationship with each of the wide variety of externalbilling mechanisms.

SUMMARY OF THE INVENTION

The present invention solves the foregoing problems by providing amethod and system that uses a single intermediate billing system toeffectuate transactions between retailers/vendors and their customersthrough a wide variety of external billing mechanisms, without the needfor the retailer/vendor to individually establish a pre-existingrelationship with each of the wide variety of external billingmechanisms.

In one embodiment, the invention is directed to a method and system forbilling a customer through an intermediary billing system for atransaction, by receiving, at the intermediary billing system, atransaction request associated with a transaction amount and a customeridentification code, validating, in the intermediary billing system, thetransaction request by determining whether the customer identificationcode corresponds to a customer that is registered with the intermediarybilling system, and sending, in the case that the transaction request isvalid, a billing event trigger associated with the customeridentification code to an external billing mechanism, the billing eventtrigger representing the transaction amount.

In another embodiment, the invention is directed to a method and systemfor billing a customer through an intermediary billing system for atransaction between the customer and a third party provider, byreceiving, at the intermediary billing system, a registration request toregister the customer, registering the customer in the intermediarybilling system by providing a mobile phone number of the customer to theintermediary billing system, assigning a customer identification code tothe customer, the customer identification code being shared with thethird party provider, and associating the mobile phone number of thecustomer with the customer identification code assigned to the customer,receiving, at the intermediary billing system, a billing request fromthe third party provider, the billing request including a productidentification code corresponding to a product associated with thetransaction between the customer and the third party provider, acustomer identification code assigned to the customer and a provideridentification code corresponding to the third party provider,validating, in the intermediary billing system, the billing request bydetermining whether the customer identification code corresponds to acustomer that is registered with the intermediary billing system, and bydetermining whether the provider identification code corresponds to avalid third party provider, and sending, in the case that the billingrequest is validated, at least one message from the intermediary billingsystem to a mobile phone number associated with the customeridentification code, the at least one message representing a billingvalue that corresponds to the product identification code.

In another embodiment of the invention, a method and system is providedfor billing a customer through an intermediary billing system for atransaction between the customer and a third party provider, byreceiving, at the intermediary billing system, a transaction activationrequest from the third party provider to activate a customer for thetransaction associated with a product offered by the third partyprovider, the customer being automatically directed from the third partyprovider to the intermediary billing system, prompting, by theintermediary billing system, the customer to confirm an instruction toproceed with the transaction, sending, in the case that the customerconfirms the instruction to proceed with the transaction, at least onemessage from the intermediary billing system to a mobile phone numberassociated with a customer identification code for the customer, the atleast one message representing a billing value that corresponds to theproduct, generating, in the intermediary billing system, an encryptedverification code in association with the customer identification codefor the customer, installing the encrypted verification code on a webbrowser application of the customer (for browsing web pages on theinternet), and automatically directing the customer from theintermediary billing system to the third party provider, receiving, atthe intermediary billing system, a verification code validation requestcontaining a returned encrypted verification code and a customeridentification code from the third party provider, and validating, inthe intermediary billing system, whether the returned encryptedverification code is the same as the encrypted verification code sentfrom the intermediary billing system to the third party provider forthat customer identification code, and sending, from the intermediarybilling system, a validation response to the third party provider, thevalidation response containing an error code in the case that thereturned encrypted verification code is not valid, and containing avalid confirmation code in the case that the returned encryptedverification code is valid, wherein the third party provider enables thecustomer to access the product on the basis of the validation responsereceived by from the intermediary billing system.

In this manner, the present invention provides that an efficient andtimely billing system that utilizes mobile text messages to billcustomers for transactions between the customers and third-partyproviders of content or services, without the need for a third-partyprovider to have any relationship or interaction with the mobile phonecarrier of the customer.

This brief summary has been provided so that the general nature of theinvention may be understood quickly. A more complete understanding ofthe invention can be obtained by reference to the following detaileddescription thereof in connection with the attached drawings. It is tobe understood that embodiments of the invention other than that providedin the description below and the accompanying drawings may be utilizedand that changes may be made without departing from the scope of thepresent invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computer system with which the presentinvention may be practiced, according to one embodiment of theinvention;

FIG. 2 is a block diagram of a mobile community environment in which theinvention may be practiced, according to one embodiment of theinvention;

FIG. 3 is a block diagram providing a detailed view of the mobilecommunity platform shown in FIG. 2;

FIG. 4 is a flowchart for explaining the registration and activation ofa customer for transaction billing, according to one embodiment of theinvention;

FIG. 5 is a flowchart for explaining the processing of a billing requestfor a transaction, according to one embodiment of the invention;

FIG. 6 is a flowchart for explaining the processing of a transaction,according to another embodiment of the invention; and

FIG. 7 is a flowchart for explaining the processing of a billing requestfor a transaction, according to another embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

As mentioned above, the present invention is a method and system thatutilizes an intermediary billing system in conjunction with one or moreexternal billing mechanisms for supporting transactions betweencustomers and third-party providers of content or services, without theneed for a third-party provider to have a relationship or interactionwith any of the external billing mechanisms.

FIG. 1 is a block diagram of an exemplary computer system with which oneembodiment of the present invention may be practiced. As seen in FIG. 1,computer system 100 includes a bus 102 or other communication mechanismfor communicating information, and a processor 104 coupled with bus 102for processing information. Computer system 100 also includes a mainmemory 106, such as a random access memory (RAM) or other dynamicstorage device, coupled to bus 102 for storing information andinstructions to be executed by processor 104. Main memory 106 also maybe used for storing temporary variables or other intermediateinformation during execution of instructions to be executed by processor104. Computer system 100 further includes a read only memory (ROM) 108or other static storage device coupled to bus 102 for storing staticinformation and instructions for processor 104. A storage device 110,such as a magnetic disk or optical disk, is provided and coupled to bus102 for storing information and instructions.

Computer system 100 may be coupled via bus 102 to a display 112, such asa cathode ray tube (CRT), for displaying information to a computer user.An input device 114, including alphanumeric and other keys, is coupledto bus 102 for communicating information and command selections toprocessor 104. Another type of user input device is cursor control 116,such as a mouse, a trackball, or cursor direction keys for communicatingdirection information and command selections to processor 104 and forcontrolling cursor movement on display 112. This input device typicallyhas two degrees of freedom in two axes, a first axis (e.g., x) and asecond axis (e.g., y), that allows the device to specify positions in aplane.

Computer system 100 operates in response to processor 104 executing oneor more sequences of one or more instructions contained in main memory106. Such instructions may be read into main memory 106 from anothercomputer-readable medium, such as storage device 110. Execution of thesequences of instructions contained in main memory 106 causes processor104 to perform the process steps described herein. In alternativeembodiments, hard-wired circuitry may be used in place of or incombination with software instructions to implement the invention. Thus,embodiments of the invention are not limited to any specific combinationof hardware circuitry and software.

The term “computer-readable medium” as used herein refers to any mediumthat participates in providing instructions to processor 104 forexecution. Such a medium may take many forms, including but not limitedto, non-volatile media, volatile media, and transmission media.Non-volatile media includes, for example, optical or magnetic disks,such as storage device 110. Volatile media includes dynamic memory, suchas main memory 106. Transmission media includes coaxial cables, copperwire and fiber optics, including the wires that comprise bus 102.Transmission media can also take the form of acoustic or light waves,such as those generated during radio-wave and infra-red datacommunications.

Common forms of computer-readable media include, for example, a floppydisk, a flexible disk, hard disk, magnetic tape, or any other magneticmedium, a CD-ROM, any other optical medium, punchcards, papertape, anyother physical medium with patterns of holes, a RAM, a PROM, and EPROM,a FLASH-EPROM, any other memory chip or cartridge, a carrier wave asdescribed hereinafter, or any other medium from which a computer canread.

Various forms of computer readable media may be involved in carrying oneor more sequences of one or more instructions to processor 104 forexecution. For example, the instructions may initially be carried on amagnetic disk of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 100 canreceive the data on the telephone line and use an infra-red transmitterto convert the data to an infra-red signal. An infra-red detector canreceive the data carried in the infra-red signal and appropriatecircuitry can place the data on bus 102. Bus 102 carries the data tomain memory 106, from which processor 104 retrieves and executes theinstructions. The instructions received by main memory 106 mayoptionally be stored on storage device 110 either before or afterexecution by processor 104.

Computer system 100 also includes a communication interface 118 coupledto bus 102. Communication interface 118 provides a two-way datacommunication coupling to a network link 120 that is connected to alocal network 122. For example, communication interface 118 may be anintegrated services digital network (ISDN) card or a modem to provide adata communication connection to a corresponding type of telephone line.As another example, communication interface 118 may be a local areanetwork (LAN) card to provide a data communication connection to acompatible LAN. Wireless links may also be implemented. In any suchimplementation, communication interface 118 sends and receiveselectrical, electromagnetic or optical signals that carry digital datastreams representing various types of information.

Network link 120 typically provides data communication through one ormore networks to other data devices. For example, network link 120 mayprovide a connection through local network 122 to a host computer 124 orto data equipment operated by an Internet Service Provider (ISP) 126.ISP 126 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the“Internet” 128. Local network 122 and Internet 128 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link 120and through communication interface 118, which carry the digital data toand from computer system 100, are exemplary forms of carrier wavestransporting the information.

Computer system 100 can send messages and receive data, includingprogram code, through the network(s), network link 120 and communicationinterface 118. In the Internet example, a server 130 might transmit arequested code for an application program through Internet 128, ISP 126,local network 122 and communication interface 118. The received code maybe executed by processor 104 as it is received, and/or stored in storagedevice 110, or other non-volatile storage for later execution. In thismanner, computer system 100 may obtain application code in the form of acarrier wave. Of course, other forms of computing systems may be used toimplement the present invention.

FIG. 2 is a block diagram of a mobile community environment in which theinvention may be practiced according to an exemplary embodiment. FIG. 2depicts a block diagram of a computer-based mobile community platform202. Mobile community platform 202 can be implemented in the computingsystem show in FIG. 1, or some other form of computing system. As seenin FIG. 2, users 212, 214, 216 can connect to the mobile communityplatform 202 via a network or similar communications channel 210. In anexemplary embodiment, network 210 is the internet by which users 212,214 and 216 can access internet-enabled applications and websites, suchas third party providers 231, 232 and 233. In this regard, third partyproviders 231, 232 and 233 can be websites that provide onlyinformation, or may be commercial websites that offer a product, such asaccess to premium content or services, for purchase by the user, wherebythe user is provided with access to the product after opting-in(purchasing) the product from that particular website. In addition,third party providers 231, 232 and 233 can be internet-enabledapplications such as a software application that is enabled to accessthe internet and that can provide content or services to the user of thesoftware application for a price. For example, a software game beingexecuted on a user's computer, or an internet-enabled game device, mayallow the user to access the internet in order to purchase additionalfeatures of the game to be downloaded or “premium” information about howto play the game for a price. It can be appreciated that a third partyprovider can be any type of application, game, product or service thatis internet-enabled and that offers additional product (software,content, information, or services) to the user for a price. Any suchthird party provider can maintain a website to which the user isdirected when the user elects to purchase a product from the third partyprovider.

Third party providers 231, 232 and 233 are maintained and operated byknown means and can be implemented in a computing system such as thatshown in FIG. 1, or other known types of networked computingenvironments, such as a server, or combination of computers and servers.By means of the connection with mobile community platform 202, a user(e.g., 212) may create a profile page or “home page” supported andmaintained by mobile community platform 202 that the user canpersonalize. This profile page can include various files and contentthat the user wants to share with other members of the mobile communityplatform 202.

The user's profile page may include a hierarchy of pages, some of whichare for public view and some of which have restrictions on viewing. Forexample, the mobile community platform 202 can be logically organizedinto neighborhoods such as “friends”, “family”, “workplace”, “dogowners”, etc. Users 212, 214, 216 can belong to these differentneighborhoods and share different pages with the members of thedifferent neighborhoods.

As seen in FIG. 2, mobile community platform 202 connects with variousmobile carrier systems 204, 206, 208, each of which has an associatedcommunity of mobile phone subscribers, 224, 226 and 228. In this regard,each of mobile carrier systems 204, 206, 208 is a carrier network andsystem for supporting mobile devices including mobile phones and othermobile devices such as personal device assistants (pda). Each mobilecarrier system is generally a wireless network provider, which can becellular, PCS, or other wireless spectrum. Users 212, 214, 216 of themobile community platform 202 are also subscribers of one or more of thevarious mobile carriers, which support the mobile phones, or othermobile devices, of users 212, 214, 216. In this way, users 212, 214, 216of mobile community platform 202 can access other users' profile pagesthrough the computer-based platform of mobile community platform 202,and they can also access the subscribers 224, 226 and 228 of the variousmobile carrier systems 204, 206, and 208 who also belong to mobilecommunity platform 202.

A significant benefit of the architecture depicted in FIG. 2, is thatthe mobile community platform 202 has pre-existing contractualrelationships with the various mobile carrier systems 204, 206, 208 foraccessing subscribers through each carrier systems and for billingsubscribers through their respective carrier system for content andservices purchased by the subscriber through mobile community platform202. As is known in the art, the mobile carrier systems 204, 206, 208provide text messaging and also premium text message functionality. Suchmessages are sent via the mobile carrier's infrastructure to its mobilesubscribers and, internal to the mobile carrier's infrastructure, thesending of such a message generates a billing event according to aparticular tariff rate, which then is added to the subscriber's billfrom that mobile carrier.

When mobile community platform 202 sends a message via a mobile carriersystem (e.g., 204), it is billing the subscriber-recipient of themessage using the existing billing system of that mobile carrier. Thebilling event is often a micro-transaction of a small monetary amount(e.g., less than one dollar). Thus, a user (e.g., 212) of the mobilecommunity platform may purchase a service or content within mobilecommunity platform 202 and be billed for those transactions through thatuser's mobile carrier service account. The present invention providesfor such micro-transaction billing support through mobile communityplatform 202 for a transaction between a user (e.g., 212) and a thirdparty provider (e.g., 231) which is external to mobile communityplatform 202. In this manner, a third party provider need onlycommunicate with mobile community platform 202 to conduct transactionswith users, and does not require any affiliation or agreement with thevarious mobile carrier systems of the users.

FIG. 3 depicts a more detailed view of mobile community platform 202. Asmentioned above, mobile community platform 202 can be used to conductmicro-transactions in which a mobile carrier's billing system is used bymobile community platform 202 to automatically bill the user for eachmicro-transactions with a third party provider, without the need for anegotiation or contract between the third party provider and the mobilecarrier. An example of this feature is a third party provider thatoperates a website which offers sports score updates to users of mobilecommunity platform 202 for a predetermined price, while taking advantageof the billing arrangements already in place between mobile communityplatform 202 and the mobile carriers 204, 206, 208. Of course, a thirdparty provider may provide other types of content, products and servicesto users of mobile community platform 202.

Turning to FIG. 3, mobile community platform 202 includes multimediamessaging system 302, user area 304, which supports content, communityand commerce functions for the users, including website interface forusers to mobile community platform 202, and intermediary billinginterface 306. The details of these different components are more fullyexplained below.

As noted earlier, users 212, 214, 216 can visit user area 304 of mobilecommunity platform 202 in order to participate in an online-basedcommunity of users that includes various communication, content andcommerce opportunities. The user accesses a website of user area 304through the user's web browser that may be hosted on a laptop or desktopcomputer, or, in the alternative, even on the user's mobile device suchas a PDA or mobile phone. In this regard, user area 304 includes a webserver that communicates with users 212, 214, 216 and includes a datastore (database) of user information and other content. With theseresources, mobile community platform 202 is able to present a profilepage (“home page”) to a user (e.g., 212) that reflects a set of content,information and products associated with, and desired by, thatparticular user. This set of content, information and products is notmaintained on the local computer being used by the user 212 but, rather,is maintained and managed by the computing environment of mobilecommunity platform 202. Although not explicitly depicted in FIG. 3, oneof ordinary skill will recognize that there are numerous functionallyequivalent techniques to create, manage, store and serve userinformation, user profiles, user content, software tools and otherresources within the user area 304. Included in these techniques aremethods to ensure security, data integrity, data availability andquality of service metrics.

Multimedia messaging system (MMS) 302 includes applications forconnecting with and communicating with the multiple different mobilecarriers 204, 206, 208 that have been partnered with mobile communityplatform 202. MMS 302 is configured to generate message requests in theappropriate format for each of the mobile carriers 204, 206, 208including tariff information that determines the amount for which therecipient of the message will be charged. Upon receipt of the messagerequest, the mobile carriers 204, 206, 208 will use the information inthe request to generate an appropriate message to the intendedrecipient/subscriber of the mobile carrier and then bill therecipient/subscriber's mobile service account for that specified amount.In this manner, mobile community platform 202 uses the mobile carriersto bill user/subscribers of the mobile carriers for transactionsconducted through mobile community platform 202.

The MMS 302 communicates with the user area 304, such that users ofmobile community platform 202 can advantageously use the connectivitybetween MMS 302 and the mobile carriers 204, 206 and 208 in order tosend messages to subscribers of any of the mobile carriers 204, 206,208. The messages may be SMS messages, MMS messages, or other knownmessage formats or subsequently developed message formats. Some of thesemessages may have zero tariff and, therefore do not generate a bill tothe recipient/subscriber (other than the underlying charges implementedby the mobile carrier) and others may have non-zero tariffs resulting ina billing event for the recipient/subscriber.

Intermediary billing interface 306 provides an interface between thirdparty providers 231, 232 and 233 and mobile community platform 202 forenabling transactions between such third party providers and users 212,214 and 216, through the use of sending messages to the users as abilling mechanism. In this regard, intermediary billing interface 306 isaccessed by the third party providers via network connection 210(internet). As seen in FIG. 3, intermediary billing interface 306 is incommunication with user area 304, both of which are in communicationwith MMS 302. Accordingly, intermediary billing interface 306 can accessuser information from user area 304, such as whether the user isregistered and verified for billing through their mobile phone number,as discussed more fully below. Intermediary billing interface 306 caninterface with user area 304 to communicate with a user, such as viawebpages supported by user area 304, for purposes of registering theuser with mobile community platform 202 and verifying the user forbilling of transactions related to a product offered through a thirdparty provider, as also discussed in more detail below.

As seen in FIG. 3, intermediary billing interface 306 also includeslocal database 310 which is used by intermediary billing interface 306to store customer identification codes, third party provideridentification codes, and other information for implementing the presentinvention. Accordingly, third party providers 231, 232 and 233 caninteract with all users of the mobile community platform 202 wherebybillable transactions with users 212, 214,216 are automatically billedto the users via the billing systems of their mobile carriers 204, 206,208. Furthermore, and importantly, this capability is available to thethird party providers without requiring them to negotiate or contractwith any of the mobile carriers for billing arrangements, or to worryabout how to communicate with a particular mobile carrier's systems andresources. The third party providers seamlessly take advantage of theunified set of connectivity and billing arrangements that exist betweenmobile community platform 202 and the mobile carriers 204, 206, 208. Asa result, the third party providers may conduct transactions withusers/subscribers of any of a variety of different mobile carrierswithout easily and efficiently through mobile community platform 202.

FIG. 4 is a flowchart that provides an exemplary depiction of theregistration and activation of a customer for transaction billing in oneembodiment of the invention. The process starts in FIG. 4 and proceedsto step 40 I in which it is determined whether the customer (e.g. one ofusers 212, 214 and 216) is initiating a transaction for a product at athird party provider, such as one of third party providers 231, 232 and233, or is initiating a transaction for a product offered by the thirdparty provider at mobile community platform 202, which acts as theintermediary billing system in either case. If the customer isinitiating the transaction at mobile community platform 202, then theprocess proceeds to step 405 which is discussed further below. On theother hand, if the customer is initiating the transaction at the thirdparty provider, then the process proceeds to step 402 in which the thirdparty provider determines if the customer is already registered as acustomer with the third party provider. If the customer is alreadyregistered with the third party provider, then the process proceeds tostep 404. If not, then the process proceeds to step 403 in which thecustomer registers with the third party provider, such as by providingthe customer's name and contact information, and in which the thirdparty provider generates a unique customer identification codecorresponding to that customer. Of course, it should be appreciated thatthe third party provider can use any form of registration process andmay not necessarily require the customer to provide any specificinformation, in which case the third party provider simply generates andassigns a unique customer identification code to that customer. In thisregard, the third party provider maintains a database of its registeredcustomers, and their corresponding customer identification numbers andinformation. The customer identification number will be used in theinvention for common tracking of the same customer between the thirdparty provider and the intermediary billing system of mobile communityplatform 202.

In step 404, the third party provider directs the customer to mobilecommunity platform 202 along with a registration request to register andactivate the customer, the request including the customer identificationcode for the customer. Next, in step 405, the registration andactivation steps for the customer begin by the mobile community platform202 (intermediary billing system) determining if the customer is alreadyregistered as a member of mobile community platform 202. If the customeris already registered with mobile community platform 202, then theprocess proceeds to step 407. If not, then the process proceeds to step406 in which the customer registers with mobile community platform 202,such as by providing the customer's name and contact information,including the customer's mobile phone number, which is used by mobilecommunity platform 202 in the invention to bill the customer for thetransaction.

If it was determined in step 401 that the customer is originating thetransaction at mobile community platform 202, then mobile communityplatform 202 also generates a unique customer identification code forthe customer. Also in the registration process, mobile communityplatform 202 stores the customer identification code for the customer ina database of registered customers, along with related information,maintained in mobile community platform 202, and activates thecustomer's mobile phone number for transaction billing as describedbelow.

Continuing with the registration and activation process, the mobilecommunity platform 202 generates a verification code for theregistration/activation of the customer, and directs the customer backto the third party provider along with the verification code, thecustomer identification code, and possibly other information, in step407. Next, in step 408, the third party provider sends a verificationcode validation request to mobile community platform 202, the requestincluding the verification code for the customer, to make sure that thethird party provider and mobile community platform 202 are in agreementon the customer identification code to be used for the customer, andthat the customer is registered and activated for the transaction inboth the third party provider and the mobile community platform 202. Inthis regard, the term “activated” means that the mobile communityplatform 202 has enabled the customer associated with the assignedcustomer identification code to be billed for transactions, such asthrough the customer's mobile phone number, or through some otherexternal billing mechanism used by mobile community platform 202.

In step 409, mobile community platform 202 determines whether theverification code received in the verification code validation requestfrom the third party provider is valid by comparing it to theverification code stored in the database of mobile community platform202 for that customer identification code. If the two codes match, thenthe verification code is valid, and mobile community platform 202 sendsa confirmation reply to the third party provider in step 411 to confirmthat the verification code is valid. If the two codes do not match, thenthe verification code is not valid, and mobile community platform 202sends an error reply to the third party provider in step 410 to advisethat the verification code is not valid. The registration and activationprocess for the customer between the third party provider and mobilecommunity platform 202 is then complete and ends.

In an exemplary embodiment of the invention, HTTP and XML are used tocommunicate between the third party provider and intermediary billingsystem of mobile community platform 202 in the steps described above. Inparticular, the registration request in step 404 is implemented with anHTTP POST, and can be passed with the following parameters:

-   -   ActionCode: 1 means to activate the customer;        -   2 means to confirm the verification code;    -   PartnerID: Assigned by mobile community platform to uniquely        identify the third party provider (partner);    -   ProductID: Assigned by mobile community platform to uniquely        identify the particular product involved in the transaction;    -   CustomerID: Customer identification code for the customer;    -   FirstName: First name of customer;    -   LastName: Last name of customer;    -   EmailAddress: Email address of customer;    -   Birthdate: Birthdate of customer;    -   Gender: Gender of customer;        Preferably, the ActionCode, PartnerID, ProductID, and CustomerID        are required parameters.

An example of HTML for the registration request is shown below in Table1:

TABLE 1 <html> <head>  <script type=“text/javascript”>   functionfrmSubmit( ) {window.document.form1.submit( );}  </script> </head>  <!--Auto submit when body loads. -->  <body LANGUAGE=“JavaScript”onload=“return frmSubmit( )”>  <form   id=“form1”   name=“form1”  action=“http://www.sms.ac/Directory/ppcoptin.aspx”   method=“POST”>  <input type=“hidden” name=“action” value=“1”>   <input type=“hidden”name=“PartnerId” value=“1234”>   <input type=“hidden” name=“ProductId”value=“5678”>   <input type=“hidden” name=“CustomerId”value=“test_user_01”>   <input type=“hidden” name=“FirstName”value=“John”>   <input type=“hidden” name=“LastName” value=“Smith”>  <input type=“hidden” name=“EmailAddress”   value=“js@ExampleEmail.com”>   <input type=“hidden” name=“BirthDate”value=“05/21/1977”>   <input type=“hidden” name=“Gender” value=“M”> </form> </body> </html>

Similarly, an HTTP POST is used in step 407 in which mobile communityplatform 202 directs the customer back to the third party provider alongwith the verification code, and the same parameter fields as discussedabove. The URL to which the customer is directed back to is specified bythe third party provider. An example of HTML for the redirect of step407 is shown below in Table 2:

TABLE 2  <html>  <head>   <script type=“text/javascript”>    functionfrmSubmit( ) {window.document.form1.submit( );}   </script>  </head>  <!-- Auto submit when body loads. -->   <body LANGUAGE=“JavaScript”onload=“return frmSubmit( )”>   <form    id=“form1”    name=“form1”   action=    “http://www.MobilePartner.com/CustomeLandingPage.html”   method=“POST”>    <input type=“hidden” name=“VC” value=   “EXAMPLE_VERIFICATION_CODE”>    <input type=“hidden” name=“PartnerId”value=“1234”>   <input type=“hidden” name=“ProductId” value=“5678”>  <input type=“hidden” name=“CustomerId” value=“test_user_01”>   <inputtype=“hidden” name=“FirstName” value=“John”>   <input type=“hidden”name=“LastName” value=“Smith”>   <input type=“hidden”name=“EmailAddress”    value=“js@ExampleEmail.com”>   <inputtype=“hidden” name=“BirthDate” value=“05/21/1977”>   <inputtype=“hidden” name=“Gender” value=“M”>  </form> </body> </html>

In the same manner, the confirmation request of the verification code instep 408 is sent from the third party provider using an HTTP POST or anHTTP GET directly between the third party provider and mobile communityplatform 202, without involving the customer's browser. The parameterfor ActionCode is set to “2” for customer confirmation. An example ofHTML for the confirmation request of step 408 is shown below in Table 3:

TABLE 3 <html> <head>  <script type=“text/javascript”>   functionfrmSubmit( ) {window.document.form1.submit( );}  </script> </head>  <!--Auto submit when body loads. -->  <body LANGUAGE=“JavaScript”onload=“return frmSubmit( )”>  <form   id=“form1”   name=“form1”  action=“http://www.sms.ac/Directory/ppcoptin.aspx”   method=“POST”>  <input type=“hidden” name=“action” value=“2”>   <input type=“hidden”name=“vc”   value=“EXAMPLE_VERIFICATION_CODE”>   <input type=“hidden”name=“PartnerId” value=“1234”>   <input type=“hidden” name=“CustomerId”value=“test_user_01”>  </form> </body> </html>

In this regard, the result for the confirmation request is written bymobile community platform 202 as plain text to the output stream, andthe possible return values for the result of the confirmation requestare:

-   -   “Success: #CustomerID# has been verified”    -   “Error: bad ‘CustomerID’: #CID#”    -   “Error: bad ‘vc’: #VC#”    -   “Error: bad PartnerID': #PID#”    -   “Error: could not verify ‘CustomerID’: #CID#” or ‘PartnerID’:        #PID#”

FIG. 5 is a flowchart that depicts the processing of a billing requestfor a transaction according to an exemplary embodiment, after theregistration and activation process described above has been completedsuccessfully. In FIG. 5, the process starts and proceeds to step 501 inwhich the customer initiates a billing event by requesting the product,such as premium content or services, for which the third party wasregistered and/or activated as described above with respect to FIG. 4.In step 502, the third party provider generates a billing request thatincludes the customer identification code, a product identification codefor the product that is the subject of the transaction, and a provideridentification code of the third party provider. Other parameters mayalso be included in the billing request.

Next, in step 503, mobile community platform 202 (intermediary billingsystem) receives the billing request described above and then performsvalidation of the billing request in step 504. The validation of thebilling request is performed by determining whether the customeridentification code in the billing request corresponds to a customer inthe database of mobile community platform 202, and by determiningwhether the provider identification code in the billing requestcorresponds to a valid third party provider in the database of mobilecommunity platform 202. If it is determined in step 505 that the billingrequest validation result is not valid, then the process proceeds tostep 506 in which mobile community platform 202 sends an error reply tothe third party provider, upon which the third party provider may refuseaccess to the product by the customer.

On the other hand, if it is determined in step 505 that the billingrequest validation result is valid, then the process proceeds to step507 in which mobile community platform 202 sends at least one message,such as a premium SMS or other type of billable message, to the mobilephone number associated with the customer identification code in thedatabase of mobile community platform 202. The message is sent frommobile community platform 202 through the carrier for the customer'smobile phone number, so that a billable amount associated with themessage is billed to the customer's account with the carrier. In thismanner, the transaction for a product between the customer and the thirdparty provider is easily supported by mobile community platform 202through the use of billable messages sent to the customer. The billingrequest from the third party provider may include a message text stringwhich is then included in the message sent from mobile communityplatform 202 to the customer's mobile phone number. Such a text stringmay be used by the third party provider to thank the customer for thepurchase, and possibly to confirm the details of the purchase, such asthe product identification, the transaction price, etc.

In step 508, mobile community platform 202 sends a confirmation to thethird party provider that the customer was billed, upon which the thirdparty provider may enable access to the product by the customer. Thebilling process of FIG. 5 then ends.

Similar to the registration and activation process, the billing requestof the invention may be formatted as XML and transmitted via an HTTPPOST to a target URL set by mobile community platform 202. The POSTparameter name is AMU, which is an XML string that contains thefollowing fields:

-   -   CommunityID: Root XML tag;    -   Authentication: Tag denotes the authentication section of the        document;    -   TransmissionID: Unique identifier for the transmission;    -   PartnerID: Unique identifier for the third party provider        (partner);    -   UserID: Community member name;    -   Password: Password of community member;    -   ProductID: Unique identifier for the product;    -   MessageText: Text to be included in premium message; and    -   CustomerID: Customer identification code for the customer.

Preferably, all of the above fields are required. An example of the XMLfor the billing request is shown below in Table 4:

TABLE 4 <?xml version=“1.0” encoding=“utf-16”?> <SMSacxmlns=“http://tempuri.org/SMSacXMLSample.xsd”>  <TransmissionId>234032832</TransmissionId>   <Authentication>    <MobilePartnerId>TestMPID</MobilePartnerId>     <!--Required; MobilePartner Username -->     <UserId>TestUserID</UserId>     <!--Required;SMS.ac Member Name -->     <Password>Password1</Password>    <!--Required; Password of your sms.ac account -->  </Authentication>   <UserOriginatedMessages>    <UserOriginatedMessage>       <ProductId>5678</ProductId>      <!--Required; The ID of the Mobile Product -->       <MessageText>       Thank you for using www.MobilePartner.com       </MessageText>      <!--Required; The Text of the Message -->      <CustomerId>test_user_01</CustomerId>       <!--Required; TheCustomer that is to be charged -->     </UserOriginatedMessage>  </UserOriginatedMessages> </SMSac>and an example XSD for the request is shown below in Table 5:

TABLE 5 <?xml version=“1.0”?> <xs:schema id=“NewDataSet”targetNamespace=“sms.ac”  xmlns:mstns=“sms.ac”  xmlns=“sms.ac”xmlns:xs=“http://www.w3.org/2001/XMLSchema” xmlns:msdata=“urn:schemas-microsoft-com:xml-msdata” attributeFormDefault=“qualified” elementFormDefault=“qualified”> <xs:element name=“SMSac”>   <xs:complexType>    <xs:sequence>     <xs:element name=“TransmissionId” type=“xs:int”      minOccurs=“1”maxOccurs=“1”/>     <xs:element name=“Authentication” minOccurs=“1”    maxOccurs=“1”>       <xs:complexType>       <xs:sequence>       <xs:element name=“MobilePartnerId” type=“xs:int”        minOccurs=“1” maxOccurs=“1” />        <xs:element name=“UserId”type=“xs:string”         minOccurs=“1” maxOccurs=“1” />       <xs:element name=“Password” type=“xs:string”        minOccurs=“1” maxOccurs=“1” />       </xs:sequence>     </xs:complexType>     </xs:element>    <xs:elementname=“UserOriginatedMessages” minOccurs=“0”     maxOccurs=“1”>     <xs:complexType>       <xs:sequence>        <xs:elementname=“UserOriginatedMessage”         minOccurs=“0”maxOccurs=“unbounded”>         <xs:complexType>         <xs:sequence>          <xs:element name=“ProductId” type=“xs:int”           minOccurs=“1” />           <xs:element name=“MessageText”           type=“xs:string” minOccurs=“1” />           <xs:elementname=“CustomerId”            type=“xs:string” minOccurs=“1” />          <xs:element name=“ChargeType”           default=“Premium”>           <xs:simpleType>            <xs:restriction base=“xs:string”>            <xs:enumeration value=“Premium”/>            <xs:enumeration value=“Standard”/>           </xs:restriction>            </xs:simpleType>          </xs:element>          </xs:sequence>        </xs:complexType>        </xs:element>       </xs:sequence>     </xs:complexType>     </xs:element>    </xs:sequence>  </xs:complexType>  </xs:element>  <xs:element name=“NewDataSet”msdata:IsDataSet=“true”   msdata:EnforceConstraints=“False”>  <xs:complexType>    <xs:choice maxOccurs=“unbounded”>     <xs:elementref=“SMSac” />    </xs:choice>   </xs:complexType>  </xs:element></xs:schema>

The possible response code for the billing request, include the errorreply of step 506 and the confirmation of step 508 in FIG. 5. In thisregard, the response codes are indicated of these replies are indicatedby a “1” for success, and a “0” for failure (error). The response of “0”for failure can also include a failure message that provides a briefexplanation of why the billing request failed.

FIG. 6 is a flowchart which provides another exemplary embodiment ofprocessing a billing transaction according to the invention. As seen inFIG. 6, the process starts and proceeds to step 601 in which a customerinitiates a billing event by selecting a product, such as premiumcontent or services, offered through the third party provider. Then, instep 602, the third party provider directs the customer to mobilecommunity platform 202 (intermediary billing system), along with aprovider identification code for the third party provider and a productidentification code for the product. This initiates the transactionactivation process. In a particular embodiment, the customer is directedto mobile community platform 202 through the use of a hyperlink.

In step 603, mobile community platform 202 determines whether thecustomer needs to login, and register if not already registered. Thecustomer does not need to login if the customer is registered and haspreviously been successfully through this process for the same product.If the login or registration is required, the process proceeds to step605. On the other hand, if the login or registration is required, theprocess proceeds to step 604 in which the customer logs in to mobilecommunity platform 202, or registers with mobile community platform 202as described above in the embodiment of FIG. 4. Next, in step 605,mobile community platform 202 prompts the customer for a confirmation ofan instruction to proceed with the transaction, and displays adescription of the product (service or content) along with the price andpossibly other information. Assuming the customer confirms thetransaction, the process proceeds to step 606, in which mobile communityplatform 202 generates an encrypted cookie that indicates the customerhas “opted in” (purchased) the product, and can therefore skip steps 603to 606 in the future for transactions involving this particular product.The encrypted cookie is then placed in the customer's browserapplication.

In step 607, mobile community platform 202 bills the customer for theproduct by sending a premium message to the mobile phone numberassociated with the customer identification code for this customer inthe database of mobile community platform 202. The billing value of thepremium message corresponds to the transaction price for the product. Inthis manner, mobile community platform 202 easily handles the billing,which may often be a micro-transaction, for third party provider throughthe use of premium messages and the existing relationships betweenvarious mobile carrier systems and mobile community platform 202. Next,in step 608, mobile community platform 202 generates a verification codethat indicates the customer has been billed for the transaction,encrypts the verification code, and places the encrypted verificationcode in a cookie on the customer's browser application. The verificationcode is also stored in the database of mobile community platform 202 inassociation with the customer identification code for this customer.Then customer is then directed back to the third party provider location(such as a website page) associated with the product of the transaction(this URL is specified by the third party provider).

The third party provider then accesses the cookie from the customer'sbrowser application and obtains the encrypted verification code. In step609, mobile community platform 202 receives a validation request fromthe third party provider, the validation request including a returnedencrypted verification code that the third party provider obtained fromthe cookie in the user's browser, along with the customer identificationcode for this customer. Then, in step 610, mobile community platform 202performs validation on the returned encrypted verification code bydecrypting it and comparing it against the encrypted verification codethat was previously generated by mobile community platform 202 for thistransaction, and confirming that the customer has been successfullybilled for this transaction. If the verification code is validated bymobile community platform 202, then flow passes to step 612 in whichmobile community platform 202 sends a valid response to the third partyprovider. If, on the other hand, the verification code is not validatedby mobile community platform 202, then flow passes to step 611 in whichmobile community platform 202 sends an error response to the third partyprovider. The third party provider then determines whether to providethe customer with access to the product based on the validation responsereceived from mobile community platform 202 (intermediary billingsystem). The process of FIG. 6 then ends.

It can be appreciated that the invention may be carried out in variousembodiments, in which some of the above described aspects may not beincluded. In this regard, FIG. 7 depicts a billing process according toanother embodiment of the invention, in which the intermediary billingsystem may be standalone and can process transaction requests from anysource for a customer and transaction amount, by using various types ofexternal billing mechanisms and billing event triggers. In FIG. 7, theprocess begins at step 701 in which mobile community platform 202(intermediary billing system) receives a transaction request, from anysource internal or external to mobile community platform 202, that isassociated with a customer identification code and a predeterminedtransaction amount. Mobile community platform 202 then performsvalidation of the transaction request in step 702. The validation of thetransaction request is performed by determining whether the customeridentification code in the transaction request corresponds to apreviously-registered and activated customer in the database of mobilecommunity platform 202. If it is determined in step 703 that thetransaction request validation result is not valid, then the processproceeds to step 704 in which mobile community platform 202 denies thetransaction request, the customer is not billed, and the process ends.

On the other hand, if it is determined in step 703 that the transactionrequest validation result is valid, then the process proceeds to step705 in which mobile community platform 202 sends a billing event triggerto an external billing mechanism in order to effectuate billing of thecustomer for the transaction amount. The billing event trigger isassociated with the customer identification code, and may actuallycontain the customer identification code, so that the external billingmechanism bills the correct customer for the transaction amount. Theexternal billing mechanism can be any type of mechanism or system forbilling the customer, such as the billing system of a mobile carrier forthe customer's mobile phone (as discussed above), a credit card billingsystem, a prepaid card billing system, a web-based payment system, abank account billing system, or any other billing system or mechanism towhich mobile community platform 202 can interface and direct a billingevent trigger for a customer. Mobile community platform 202 cansimultaneously use several different external billing mechanisms, andmay use one or several of them for each customer depending on the typeof third party providers with which the customer conducts transactions.Accordingly, mobile community platform 202 acts as a virtualpoint-of-sale for third party providers to enable the payment fortransactions through the use of one or more external billing mechanismswith which mobile community platform 202 has a pre-existing relationshipfor authorized use of the external billing mechanisms.

Similarly, the billing event trigger can be one of many different typesand formats, depending on the external billing mechanism to which thebilling event trigger is sent for the customer, and the pre-existingarrangement (if any) that mobile community platform 202 has with theexternal billing mechanism. For example, in the case that the externalbilling mechanism is the billing system of the mobile carriercorresponding to the customer's mobile phone number, then the billingevent trigger can be a message, such as a premium SMS, MMS, or othertype of billable message, that is sent from mobile community platform202 to the customer's mobile phone number through the mobile carrier. Inthe alternative, other types of billing event triggers can be used withthe external billing mechanism. For example, the billing event triggersent to the mobile carrier billing system can be a billing record filewhich contains the transactions for a customer that will then be addedto the customer's carrier bill by the mobile carrier billing system. Asmentioned above, other types and forms of billing event triggers thatcan be used by mobile community platform 202 include messages such asSMS, MMS, email, file transfers, XML, HTTP, billing record transfers, orany other type of communication supported by the internet, encrypted orunencrypted.

The transaction request from the third party provider may include amessage text string which is then included in the message sent frommobile community platform 202 to the customer's mobile phone number.Such a text string may be used to thank the customer for the purchase,and possibly to confirm the details of the purchase, such as the productidentification, the transaction price, etc. The process of FIG. 7 thenends. It can be appreciated that the general billing system depicted inFIG. 7 provides a powerful, efficient and convenient way with which tobill customers for various types of transactions by using an existinginterface between mobile community platform 202 and one or more externalbilling mechanisms.

While the present invention has been particularly described above withreference to the various figures and embodiments, it should beunderstood that the invention is not limited to the above-describedembodiments. Various changes and modifications may be made to theinvention by those of ordinary skill in the art without departing fromthe spirit and scope of the invention.

1. A method for billing a customer for a transaction between thecustomer and a third party provider, the method including: aregistration request receipt step of receiving, at the intermediarybilling system, a registration request to register the customer; acustomer registration step of registering the customer in theintermediary billing system by providing a mobile phone number of thecustomer to the intermediary billing system, assigning a customeridentification code to the customer, the customer identification codebeing shared with the third party provider, and associating the mobilephone number of the customer with the customer identification codeassigned to the customer; a billing request receipt step of receiving,at the intermediary billing system, a billing request from the thirdparty provider, the billing request including a product identificationcode corresponding to a product associated with the transaction betweenthe customer and the third party provider, a customer identificationcode assigned to the customer and a provider identification codecorresponding to the third party provider; a billing validation step ofvalidating, in the intermediary billing system, the billing request bydetermining whether the customer identification code corresponds to acustomer that is registered with the intermediary billing system, and bydetermining whether the provider identification code corresponds to avalid third party provider; and a billing step of sending, in the casethat the billing request is validated, at least one billable messagefrom the intermediary billing system to a mobile phone number associatedwith the customer identification code, the at least one messagerepresenting a billing value that corresponds to the productidentification code.